前言：「順便看一下」跟「專門檢查」是兩件事

「反正 code review 都交給 AI 了，架構有沒有違規，AI 應該也會順便看到吧？」

這句話聽起來合理，卻藏著一個容易被忽略的落差。一般的 code review——邏輯對不對、有沒有邊界情境沒處理、測試斷言精不精確——跟「這段改動有沒有違反分層規則、依賴方向對不對」是兩種完全不同的檢查。前者看的是「這段程式碼本身寫得好不好」，後者看的是「這段程式碼放在系統裡的位置對不對」。如果只交代 AI「順便看一下」，兩種檢查很容易只做到第一種，因為它更直覺、更容易從程式碼本身看出來。今天要講的，就是為什麼架構審查值得被設計成一個獨立的角色，而不是塞進一般 code review 的待辦清單裡。

今日目標

• 理解「程式碼品質審查」跟「架構違規審查」為什麼需要不同的檢查標準
• 認識架構審查需要哪些一般 code review 不會主動查證的脈絡
• 看一組具體的❌/✅對照，分辨「順便看看架構」跟「專門設計架構審查角色」的差異
• 建立一套讓架構審查角色能實際運作的具體做法

為什麼「順便看」看不到架構違規

一般的 code review 委派給 AI 時，通常的指令是「幫我看看這段改動有沒有問題」——這類指令會讓 AI 依賴它讀程式碼當下能直接看出來的線索：邏輯有沒有明顯錯誤、測試斷言精不精確、有沒有潛在的例外狀況沒處理。這些線索都在改動的 diff 裡，AI 不需要額外查證什麼就能判斷。

架構違規不一樣。「這個改動有沒有違反依賴方向」這件事，沒辦法只看 diff 本身判斷——AI 得知道整個系統的分層規則長什麼樣、這個檔案在架構裡屬於哪一層、它現在依賴的那個模組又屬於哪一層。 這些脈絡通常不會寫在改動的 diff 裡，而是散落在專案的架構文件、目錄結構慣例、甚至團隊共識裡。如果沒有明確要求 AI 去查證這些脈絡，它只能憑「這段程式碼讀起來合不合理」的直覺判斷，而依賴方向這種違規，讀起來往往完全合理——程式能編譯、邏輯也對，只是「這一層不該依賴那一層」這件事，不會反映在程式碼的正確性上。

兩種審查需要的輸入不一樣

一般 code review 需要的輸入很單純：改動的 diff、對應的測試。架構審查需要的輸入更多：

• 這個專案的分層規則本身（哪些層可以依賴哪些層，這件事通常寫在架構文件或 ADR 裡，不會寫在程式碼裡）
• 改動涉及的每個檔案在架構裡的定位（這個 Controller 屬於哪一層、那個被新引入的依賴屬於哪一層）
• 理想情況下，一份可執行的檢查結果（如果專案已經有 Day 17 講的靜態分析工具，架構審查角色的第一步應該是先跑這個工具，把可以機械判斷的違規直接列出來，再讓 AI 判讀那些工具抓不到、需要脈絡理解的部分，例如「這個依賴表面上没有違反規則，但語意上其實不該存在」這類判斷）

用一組對照來看這個差異：

❌ 順便看一下架構：
「幫我 review 這段改動有沒有問題。」
→ AI 檢查邏輯、測試、邊界情境，
  沒有主動去查證這個改動有沒有違反分層規則，
  因為分層規則不在它讀到的 diff 裡

✅ 專門設計架構審查角色：
「這是我們專案的分層規則：[分層規則來源]。
 先跑一次靜態分析工具的違規清單；
 針對清單裡每一項，判斷這是不是真的違規，
 還是工具的假陽性；
 再額外檢查一次工具規則範圍之外、
 但語意上可能有問題的依賴關係。」
→ AI 被明確要求帶著分層規則跟工具結果去查證，
  而不是只憑改動本身的可讀性判斷

架構審查角色的核心價值，不是找一個更聰明的 AI，而是把「這個改動有沒有問題」這個籠統問題，拆解成「架構規則是什麼、這個改動有沒有查證過符合這些規則」這個具體流程。 這跟這個系列從 Day 01 開始反覆講的邏輯是一致的：AI 給出的「已檢查過」結論，只在它實際查證的範圍內成立——如果它從沒被要求查證架構規則，那「已經 review 過了」這句話,自然也不包含架構違規這個維度。

兩種審查該分開跑，還是合併跑

實務上，架構審查角色可以是一個獨立的 agent（拿到改動的 diff 跟架構規則文件，只回答「有沒有違反架構規則」這一個問題），也可以是同一個 code review 流程裡明確拆出來的一個步驟（先做一般品質審查，再切換脈絡做架構審查）。兩種做法的共同點是：架構審查要有自己明確的檢查清單跟輸入來源，不能只是「品質審查的時候順便注意一下架構」這種模糊的附加要求。

分開設計還有一個好處：品質審查跟架構審查各自產出的結果性質不同——品質審查的結論通常是「這裡建議這樣改」，架構審查的結論往往是「這個依賴不該存在，需要重新設計」，後者的影響範圍通常更大，值得單獨被看見，而不是被淹沒在一堆風格建議裡。

今日思考題

回想你上一次委派 AI 做 code review：那次的指令裡，有沒有明確要求它查證架構規則？如果沒有，你怎麼知道那次 review 到底有沒有涵蓋架構違規這個維度？

今日重點回顧

• 一般 code review 看「程式碼本身寫得好不好」，架構審查看「這段程式碼放在系統裡的位置對不對」，兩者需要的檢查標準跟輸入不同
• 架構違規往往在程式碼正確性上完全合理，只有對照分層規則才看得出問題，AI 沒被要求查證就看不到
• 架構審查需要額外輸入：分層規則本身、改動涉及檔案的架構定位、理想情況下先跑靜態分析工具的結果
• 架構審查值得設計成獨立角色或獨立步驟，而不是塞進一般品質審查的待辦清單裡

明日預告

明天用一個具體案例，展示設計好的 AI 架構審查角色實際抓到了什麼——一個違反分層規則的隱藏耦合，在一般 code review 裡完全看不出問題,只有專門查證架構規則才浮現出來。